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ABSTRACT 



This thesis reviews the topic of software reusability 
with special emphasis upon the reusability of products of 
the design phase of the software life cycle. The ideas of 
software reuse as a capital-intensive process and reuse of 
products of all phases of the software life cycle are also 
presented. The thesis presents a formal definition of the 
term software reusability, presents a hypothetical design 
scenario incorporating reuse, and compares the requirements 
of a reusable software design methodology with features of 
existing design methodologies. Other issues pertinent to 
software reuse in general, and reuse of design in particular, 
are reviewed. 
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I. 



INTRODUCTION AND BACKGROUND 



A. THE SOFTWARE CRISIS 

The motivation behind research into reusable software 
lies in the current software crisis and in reusable software's 
possible role in alleviating that crisis. The term software 
crisis denotes a situation within the computer industry in 
which production and maintenance of computer systems is 
"bottlenecked" by the software components of these systems. 
This represents a reversal of the situation in the late 
1940 's and 1950's when difficulties in system development 
were primarily caused by hardware. Indeed, much attention 
in software development during this period was given to the 
optimization of scarce hardware resources. 

Since the beginning of the computer industry in the late 
1940 's, hardware production has been marked by two trends 
which have reduced the hardware bottleneck and resulted in 
the current software crisis. The first of these is the ad- 
vancement of hardware technology; that is, from vacuum tubes 
to transistors to integrated circuits. The result is the 
elimination of hardware as a scarce resource in many systems. 
Second and more important, the application of techniques of 
mass production, borrowed from other industries, is changing 
the production of computer hardware from a custom craft to a 
true assembly line process where multiple, identical units 
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are produced over extended production runs . The hardware 
side of the computer industry is following the pattern of 
automobile, household appliance and other industries. 

These same trends are not present in production and 
maintenance of computer software. Indeed, software design 
is viewed as being analogous to production of artwork or an 
exspensive automobile. It is a task in which components are 
individually developed by highly skilled artisans and 
meticulously fitted together. Pieces which later on prove 
to be faulty or must be altered to meet new environmental 
constraints must be customized or replaced by a similar 
process. Despite piecemeal attempts to automate various 
stages in software production, the entire process remains an 
extremely labor intensive endeavor which starkly contrasts 
to the capital intensive nature of hardware production. 

Recognition of existence of a crisis in software produc- 
tion and maintenance is generally thought to have occurred 
in the late 1960's, beginning with the NATO Software Con- 
ference in 1968. At this time, the industry first began to 
perceive that the real impediment to production of computer 
systems lay not in hardware but in software. Since this 
conference, attention is now focused on methods to eliminate 
the software bottleneck. An examination of some more impor- 
tant ideas, developed during this period which may have a 
bearing on resuable software, is now in order. 



8 



1. Structured Programming 



Edsger Dijkstra is generally credited with popularizing 
the concept of structured or "go-to-less" programming. 

This began in 1968 with publication of his letter to the 
editor of the Communications of the ACM [Ref. 1] and has 
become a widely accepted technique of good programming. Its 
essence is summarized as being replacement of random, hap- 
hazard program structure with purposeful, cogent, nonrandom 
structure. This structure, it is asserted, is easier to 
understand, thus facilitating development and maintenance. 
Structured programming is associated with third and fourth 
generation block-structured languages which emphasize nested 
blocks of code. 

2 . Modularization 

Modularization is an important development which is 
closely linked with structured programming. Modularity 
involves decomposition of complex programs into smaller 
segments or modules; each module performs a relatively simple 
and independent function. In this manner software becomes 
more manageable, more flexible and more comprehensible 
[Ref. 2] . 

3 . Information Hiding 

David Parnas is considered to be the originator of 
the concept of information hiding [Ref. 3]. This is the 
principle that the implementor of a module should possess 
only information needed to implement that module and nothing 
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more and that the user of a module should possess only 
information needed to use that module and nothing more. 

This thesis views structured programming, modularity 
and information hiding as concepts which can assist in effi- 
cient production of software; they make the production of 
software analogous to that of stereo equipment in which 
components are modularized and can be easily interchanged. 
Much of the literature on reusability recognizes that the 
concept of interchangeability should apply to software 
production; more efficient software production should be a 
consequence . 

4 . Software Life Cycle 

An important occurrence since 1968 is the recognition 
that the production of software is a multi-stage process and 
not a single event in time. Rather than viewing production 
of software as simply production of program code, software 
engineers now emphasize that most software effort and costs 
occur during tasks other than coding. This view of software 
production as a time-sequenced, multi-staged process is 
known as the Software Life Cycle, of which there are many 
versions. For this thesis, Barry Boehm's Waterfall Software 
Life Cycle Model is used and appears as Figure 1. It is per- 
ceived that overall solutions to the software crisis can not 
focus exclusively on any single stage of the software produc- 
tion cycle; instead, all stages must be considered. 

Overall, the history of the software crisis is still 
in the process of evolution with no final solution to the 
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Figure 1. Waterfall Software Lifecycle Model 
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effective production of software yet having been found. 

Each of the ideas mentioned above, as well as other develop- 
ments not mentioned, represents a partial solution. This 
thesis believes the software crisis results from an inability 
to convert a labor intensive production process into a capital 
intensive process; that is, to introduce automation and 
other techniques that utilize capital products, such as 
existing software components, into software development. Key 
to this conversion is a concept which has only recently been 
recognized as having potential to alleviate the software 
crisis. This is the concept of reusable software. A more 
precise definition of the concept awaits Chapter II of this 
thesis, but for now it is simply defined as reuse of software 
components within single programs and among multiple programs. 
Just as early industrialists saw that the key to mass produc- 
tion of tangible goods was development of standardized com- 
ponents which could be used interchangeably, so is reuse of 
standardized, interchangeable software components the key to 
imrpovea production of software products. 

B. OVERVIEW OF SOFTWARE REUSABILITY 

As a concept and as an implemented practice, reusable 
software has a very short history. For convenience, this 
history is divided into three periods. First is the period 
from 1968 until 1978. The oldest known reference to reusa- 
bility as a concept, in and of itself, occurred in a paper 
by Doug Mcllroy at the 1968 NATO Conference on Software 
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Engineering [Ref. 4]. At this conference, Mcllroy advocated 
a "component manufacturing facility" utilizing a parameterized 
family of routines. Horowitz and Munson mention that his 
work was criticized for various reasons [Ref. 5] , and the sub- 
ject of software reuse seems to have disappeared for the next 
ten years. Of the articles either about software reuse or 
containing references to reuse, one finds none before 1978, 
other than Mcllroy' s. The second period occurs from 1978 to 
1981 and is termed the "buzzword phase" by this thesis. During 
this period references to reusability occurred in the computer 
literature; however, they primarily cited the concept, 
usually as a possible solution to the software crisis. Most 
of the literature on reusability in this period is devoid 
of significant analysis of the concept, exceptions being those 
articles written by Robert Lanergan [Refs. 6-8]. Reusability 
during this period is, therefore, merely a "buzzword" which 
most authors mention without seriously analyzing. Of approxi- 
mately 20 individual articles written on the subject, well 
over 60% have been written since 1981, which is the final 
period. This period is characterized by increased emphasis 
and analysis of reusability as a potential solution to the 
"software bottleneck." Research into reusability has increased 
and has been more in depth since 1981; indeed, two conferences 
have been held since then, one partially devoted to the 
subject, the other totally devoted to reuse of software. 
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1 . Software Reusability Literature 



The literature on software reusability consists of 
approximately 20 individual articles and the proceedings of 
two conferences. Perhaps most important of the articles are 
a series done by Robert Lanergan and others of Raytheon, Inc. 
describing that corporation's actual implementation of a 
reusable code methodology in software application development 
[Refs. 6-8] . Two articles by Rauch-Hindin explore possible 
gains from implementing reusable software as well as implemen 
tation obstacles [Refs. 9-10]. In two articles, Peter Wegner 
is the first to recognize software production as a capital 
intensive process and emphasize reusability's role in that 
process [Refs. 11-12] . In the IEEE Tutorial on Software 
Design Techniques , Peter Freeman published one of the first 
in-depth, analytical discussions of the concept [Ref. 13]. 
Most of the remaining literature on reusability, except that 
below, is characterized as being isolated, superficial over- 
views of, or references to, the subject. 

2 . NPGS Software Workshop 

Due to its limited distribution, the Proceedings of 
the Software Workshop [Ref. 14] held at NPGS, Monterey, Ca . , 
is not included in the literature cited above. At this 
workshop, one of the panels was devoted exclusively to the 
topic of software reusability. Although oriented toward a 
DOD perspective, most of the panel's analysis applies to 
reusability in general and represents the first attempt to 
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analyze the subject comprehensively. Especially important 
is the panel 1 s consideration of life cycle implications for 
reuse of software; prior to this report, the literature 
seems to focus on reuse of code alone. In addition, the 
Workshop attempts to deal with some of the "how to" questions 
of reuse implementations, which were previously ignored. 

3 . ITT Workshop on Reusability 

Most recently, ITT sponsored a workshop solely devoted 
to reusability and subsequently published the proceedings. 
Unlike the NPGS workshop which represents a unified approach, 
the ITT Proceedings [Ref. 15] is a collection of articles on 
a variety of reusability topics. As such, a multiplicity of 
concepts and viewpoints are presented with no single focus. 
However, the diversity of ideas is an asset. 

4 . Software Reuse Implementations 

Perhaps the one aspect of software reusability which 
most reveals its immaturity is the number of actual implemen- 
tations. As mentioned above, Raytheon, Inc., appears to be 
the first and most extensive implementation of reusability. 
This is a data processing implementation using COBOL as 
source language. Other implementations include Hartford 

Insurance Company, Security Pacific Bank in Los Angeles, 

2 

Houghton Mifflin and Xerox . 

The literature on software reuse cites several 
different computer applications as examples of existing 



Personal telephone conversation with Robert Lanergan. 
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forms of reuse. For example, Horowitz and Munson list the 
following : 

1. subroutine libraries 

a. general libraries — utilities, etc. 

b. specific application areas — SPSS, etc. 

2. compilers 

3. simulation — GPSS, etc. 

4. parameterized systems — automated program development 
based on user supplied information [Ref. 16] . 

Standish cites seven examples of existing forms of reuse: 

1. mathematical subroutine libraries 

2. operating system service calls 

3. small granule capabilities — UNIX 

4. large granule tools — EMACS 

5. reuse of algorithms from books 

6. software application generators 

7. Japanese software factories [Ref. 17]. 

There are several conclusions to be drawn from the 
above lists. First, there is no agreement in the general 
literature on a standard definition of software reusability. 
As it will be derived in the next chapter, the definition of 
reusable software according to this thesis excludes several 
of the examples cited above. For example, our definition 
excludes subroutine libraries because their reuse requires 
no adaptation, nor are they reused in end uses different 
from that for which they were originally developed. This 
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illustrates the need for a standard definition of the term. 



Second, those existing examples which can be classified as 
reuse by our definition are few and fairly recent; e.g., 

UNIX. This is to say that the field has not been innundated 
with experiments, much less been given serious consideration. 
Prior to 1978, the current concept of reusability, in and 
of itself, did not exist. 

C. OUTLINE OF THESIS 

Thus far this thesis has explored briefly the nature of 
the software crisis; it has been asserted that this arises 
from disparities between hardware and software production 
techniques. The former is more capital intensive, while the 
latter is more labor intensive. Finally, software reusa- 
bility has been proposed as a key element in the "capitaliza- 
tion" of software production. As the brief overview of 
reusability shows, research on the specifics of implementing 
reusability is scant and fragmented at best. 

This thesis seeks to add another building block to the 
structure which has been started by others. For reasons 
which will become clear in subsequent chapters, this task is 
best accomplished by an analysis focusing on the design stage 
of the software life cycle and its implications for reusa- 
bility. However, this requires that adequate attention be 
given to the whole concept of software reuse. Two major 
subtasks are necessary. First, a synthesis of existing, 
important knowledge is required; this is attempted in this 
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chapter and Chapter II, where software reusability is de- 
fined. This synthesis continues throughout the remaining 
chapters. The second major subtask is to develop a framework 
for understanding and implementing reusability. This is 
done by adoption of a design perspective in Chapters III, 

IV and V. Chapter III specifically overviews software 
design. Chapter IV reviews the literature on reuse of design, 
and Chapter V develops guidelines for a reusable design 
methodology. Chapter VI develops other issues pertinent to 
software reuse in general that also affect the design issue. 
Chapter VII contains conclusions and recommendations. 
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II. DEFINITION OF REUSABLE SOFTWARE 



The purposes of this chapter are to fill a void regarding 
the exact meaning of the term "reusable software" and to 
understand its software life cycle implications. What is 
meant by the term? What types of software does it encompass? 

Is an operating system which is continually reused by appli- 
cation programs to be considered reusable software? Are 
off-the-shelf commercially purchased programs which are used 
in their entirety to be considered as reusable software? 

Until now, the majority of references to the term have not 
attempted to answer these kinds of questions, nor have they 
attempted to define the term itself. Most references tend 
to refer to the term as if it were an intrinsically worthy 
objective whose meaning is intuitively understood. Our pur- 
pose must be to bring more precision to the term, so that 
further research into characteristics and structure of reusable 
software may be based on a concrete understanding of the term. 

A. SOFTWARE AS CAPITAL 

An understanding of reusable software begins with knowl- 
edge that it is part of a process; the previous chapter 
alludes to this, but it must now be made more explicit. The 
process under consideration is the creation of software 
products, primarily the generation of programs to be run on 
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computer hardware. This process is labor intensive, but 
attempts are being made to make it more capital intensive. 

It is today less labor intensive than it was thirty years 
ago, a trend which hopefully will continue. "A production 
process is capital-intensive if it involves expenditures early 
in its life cycle for the purpose of increasing productivity 
later in the life cycle" [Ref. 18] . Additionally, Wegner 
defined capital as a reusable resource, the cost of which 
can be distributed over the "set of actual or potential uses" 
of that resource [Ref. 19]. Thus, the heart of a capital 
intensive software production process is the existence of 
certain resources that can be utilized more than once after 
their initial development. Development costs for these re- 
sources should, in some way, be partitioned among users of 
this resource. 

The problem of converting software production from a 
labor intensive into a capital intensive process actually 
involves two separate but related elements. First, it is a 
desirable, but not necessary, goal to automate the production 
process; this entails the substitution of computer effort 
for human effort into as many phases of the software life 
cycle process as possible, particularly in the latter stages 
of coding, integration, implementation and maintenance. Second, 
and more important, is that techniques that use existing 
components must be introduced into software development. 

What we are really seeking is not the ability to produce 
software by computers, although this is a worthy objective; 
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rather, we seek to produce software in greater quantities, 
just as automobiles or computer hardware are produced. 

In classical economics, mass production is accomplished 
when an entrepreneur combines the three factors of production — 
land, labor and capital — via his organizational talents. 

The factory organization so constituted receives raw materials 
as inputs and processes them through the factory, and mass 
produced outputs result. In our modern economy, generally 
the entrepreneur is replaced by some form of corporate organi- 
zation, but the basic process remains. 

Although once developed, software can be replicated rela- 
tively simply, it is its development which remains labor 
intensive. The three factors of production in its development 
are primarily labor, combined with small amounts of land and 
capital. What is sought is a production oriented design 
process similar to the design processes involved in architec- 
ture, computer hardware development and other industries. In 
such a software design process, designs can be produced using 
standard components, standard design techniques and standard 
forms of communication. In such a system, capital becomes 
the dominant factor of production as software components, the 
raw materials of the system, become inputs to a "software 
factory." Application programs become the outputs. The 
unique thing about production of software under such a 
system is that software components, in addition to being raw 
materials, are also the capital of the organization since they 
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are resources which can be utilized more than once after 
their initial development. Thus, reusable software components, 
along with computer hardware and any other equipment, comprise 
the capital of a software factory. 

In equating software design with other forms of design, 
in this case computer hardware design, an interesting 
comparison occurs. Generally, the design process can be 
modelled as 

"Design Idea" + "Standard Components" = "Finished Product" 

Historically, hardware design is characterized by an increase 
in the size (i.e., number of units contained in a given com- 
ponent) of its standard components. Hardware design in the 
early 1950's, for example, is characterized by techniques 
where the largest standard component consisted of one or a 
few gates; now, it is a microchip containing hundreds of 
thousands of gates. Thus, hardware designers no longer have 
to work at the gate level; instead, they work at the register, 
or more likely, processor level. On the other hand, a 
corresponding increase in size has not occurred in software 
design. Even though software developers worked at the 
machine or assembly language level in the 1950 's, they now 
work at the programming language statement level. To have 
maintained comparability with hardware designers, they should 
be designing with components comprised of thousands of 
programming language statements (or some elementary component 



22 



of an earlier stage in the software life cycle) . This level 
might be termed the module level. If this were the case, 
software design would become more capital intensive, and the 
capital component of software development would be improved. 

B. LIFE CYCLE IMPLICATIONS 

Having limited the term reusable software to mean reusable 
software resources of a capital nature, the concept must 
now be further refined; as it now stands, it is much too 
broad and all encompassing. Peter Freeman succintly puts 
it: 

We are not interested in the very important reuse of 
programs by multiple end-users upon multiple occasions 
(operating systems for example) ... the focus is on the 
information needed by the developer (or maintainer) . 

[Ref. 20] 

It is important to distinguish the difference between mere 
reuse of an entire program without modification or adaptation 
and incorporation of a component or an entire program into 
another program, the product being a completely new program. 

We will define the latter to be an instance of reusable soft- 
ware, while the former is not. What is of interest is a 
function for which no previously known program exists and 
for which a completely new entity must be created, either by 
developing new programs or by combining/adapting previously 
existing structures. 

A related problem which has frequently plagued uses of 
the term reusable software in the literature is the question 
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of which reusable software resources of a capital nature are 
to be used in the development or maintenance of new software 
end uses. What sort of resources does this include? A common 
misconception seems to be that these resources only include 
program code itself and nothing else. One of the first groups 
to recognize the fallacy of this idea was the Panel on Soft- 
ware Reusability sponsored by the Joint Logistics Commanders. 
They defined reusable software to include "specification, de- 
sign, code, and/or documentation" [Ref. 21]. Reusability must 
be viewed as encompassing the entire software life cycle, not 
just the implementation phase of the process. Indeed, Freeman 
stated that "reuse of program code alone has almost no value" 
[Ref. 22]. He proposes a hierarchy of types of information 
which can be reused; this is presented in Figure 2. The 
value of this diagram is its visual display of the wide array 
of software knowledge which may be reused. It conveys only 
an intuitive notion. The five levels of reusable information 
shown on the right hand side can be combined into three cate- 
gories which more accurately portray major categories of 
reusable information: 

1. external/environmental information — this category 
includes system documentation, requirements analyses, 
and other pre-design information; 

2. logical structures/functional architectures — design 
information; 

3. code fragments — program code, program documentation, 
test results, and other post-design information. 
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Hierarchy of Information 



From Freeman's definitions of these levels in the hierarchy, 
it is evident that he intends reuse of software resources to 
be comprehensive. This thesis will also adopt this view. 

This thesis utilizes the software life cycle framework as 
presented in Figure 1. Other frameworks are available; how- 
ever, most reduce to a basic structure consisting of four 
primary stages: (1) determination of requirements, (2) design, 

(3) implementation and (4) operations. Differences are 
usually accounted for by the subdivisions of each of these 
four stages. As was mentioned in Chapter I, our emphasis is 
on the design stage, for this is perceived to be the crucial 
stage for implementing reusable software; however, in defining 
the term, all phases of the life cycle must be included. 

C. DEFINITION 

Reusable software is defined as software resources of a 
capital nature which are used in the development or maintenance 
of software products with end uses different from that of 
the component resources. These resources encompass any 
information generated at any time throughout the software 
life cycle. A component resource is described as a modular 
product of the software life cycle, possessing the character- 
istic of being highly cohesive. 
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III. OVERVIEW OF SOFTWARE DESIGN 



The analysis of the design stage and its importance to 
reusable software begins by first describing the software 
design process. The second section of this chapter then 
reviews current design methodologies in order to gain a 
more detailed understanding of this process. 

A. DESCRIPTION OF SOFTWARE DESIGN 

While the requirements determination stage of the soft- 
ware life cycle specifies what is to be done, the design 
phase tells how to do it. The design process is an attempt 
"to achieve fitness between two entities: the form (problem 

solution) in question and its context (problem definition) " 
[Ref. 23] . Emphasis is on hierarchy, allocation of resources 
and satisficing [Ref. 24] . Freeman lists three purposes of 
design : 

1. Discovery of problem structure. 

2. Creation of solution outlines. 

3. Review results in comparison with goals [Ref. 25]. 

Thus, the design process begins with some sort of problem 
stated as a requirement and produces a matching solution to 
that problem, expressed in one of many ways. 

Most authors divide software design into two distinct 
phases. First is architectural or high level design where 
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"emphasis is on determining the structure of the system, 
decomposing the system into modules, and precisely speci- 
fying the interfaces between the modules" [Ref. 26] . Second 
is detailed design in which algorithms are selected to 
implement modules developed in the architectural phase. The 
end result of software design is a representation of the 
system which can be used by the implementor. 

B. CURRENT DESIGN METHODOLOGIES 

Before discussing specific design techniques, there are 
five overall approaches to software design that one must 
consider. According to Freeman, these are: 

1. Top-down — begin at the highest level of abstraction, 
then work down through successively lower levels. 

2. Bottom-up — opposite of top-down in that lower level 
decisions are made first, emphasizing internal criteria. 

3. Outside-in — essentially same as top-down with the 
sense of direction defined in terms of what the user 
sees . 

4. Inside-out — opposite of outside-in since the implemen- 
tation decisions are made before external (user-oriented) 
decisions . 

5. Most-critical-component-f irst — most constrained or 
critical components are designed first [Ref. 27]. 

Of specific existing design techniques, six popular ones are 
examined. The first three of these may be classified as 
architectural design techniques, while the last three are 
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detailed design techniques. Intent of this discussion is 
not to provide a cumulative, detailed discussion of design 
techniques. These six are chosen as a basis to show how the 
problem of implementing a reusable design methodology may be 
approached; they are also chosen because they represent 
differing approaches to design and thus offer an opportunity 
to examine reuse from many facets. 

1 . Structured Design 

Structured Design is a technique normally associated 
with Constantine, Yourdon and Myers and is a graphical 
technique which utilizes a notation called a structure chart. 
Although similar in appearance to a traditional flowchart, 
a structure chart is based upon the concept of a module which 
refers "to a set of one or more contiguous statements having 
a name by which other parts of the system can invoke it" 

[Ref. 28] . Structure charts are developed using the following 
process : 

1. Develop a functional picture of the problem. 

2. Identify external conceptual streams of data. These 
are streams external to the software system and are 
independent of any physical input/output device. 

3. Determine the points of highest abstraction from the 
major external conceptual stream. For an input steam, 
this point is where "data is fartherest removed from 
its physical input form yet can still be viewed as 
coming in." For an output stream, this occurs where 
the data is first viewed as going out. 
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4 . 



Develop source and sink modules for each input and 
output stream at points of most abstract input and 
output data. Each module's function is described with 
a concise phrase, as well as any transformations that 
occur when that module is called. 

5. Identify the last transformation necessary to produce 
the form being returned by each source module as well 
as the form of input prior to that transformation. 

For sink modules, identify the first process necessary 
to get closer to the desired output, and the resulting 
output form. Repeat on new source and sink modules 
until the original source and final sink modules are 
reached. 

In general, the structure of the design should mesh 
with that of the problem, and scope of effect of a decision 
should be within the scope of control of the module contain- 
ing that decision. This reduces intermodule communication 
problems. Structure charts are useful in modular designs 
since they explicitly show module connections and module 
parameters. Since they contain no decision blocks, decisions 
are deferred until the detailed design stage; this allows 
design to proceed at a fairly abstract level. Stevens, et 
al., characterize the technique as emphasizing simplicity, 
low coupling and high cohesion of modules, and predictability 
(i.e., a module operates the same every time it is called, 
independent of its external environment) [Ref. 29] . 
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2. HIPO 



HIPO (Hierarchy plus Input-Process-Output) is a 
graphical technique consisting of two basic components: a 

hierarchy chart and input-process-output charts. Even though 
it does contain textual material, like Structured Design, it 
relies heavily upon diagrams and, for this reason, is con- 
sidered to be primarily graphical. Originally, HIPO was 
intended to be used as a documentation tool in conjunction 
with Structured Design. As an iterative, top-down process, 

HIPO first involves describing a function as a series of 
steps in terms of inputs and outputs. This is done via the 
input-process-output diagram which is developed concurrently 
with the hierarchy chart. At the completion of each level, 
those functions included in the process box are themselves 
then subjected to the same analysis. This iterative process 
permits abstraction of functions into modules which have the 
following properties: 

1. single entry point 

2. single exit point 

3. small size 

4. structured nature [Ref. 30]. 

Input-Process-Output Charts represent a good documentation 
technique for describing functions appearing in Hierarchy 
Charts; however, they seem to be deficient relative to 
Structured Design in their ability to communicate module 
interfaces, a critical issue in any reusable design methodology. 
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3 . DREAM 



DREAM (Design Realization, Evaluation and Modelling) 
is a nongraphical technique which utilizes a design descrip- 
tion language called DREAM Design Notation (DDN) . DREAM sup- 
ports a hierarchical design approach in that DDN descriptions 
are of classes of components within a system which are decom- 
posible into subcomponents in an iterative manner. An event 
based design method is used in which pertinent events in the 
system are identified, constraints upon these events are 
developed, system components necessary to produce these 
events are identified, and interactions among these components 
are developed. DREAM is supported by an automated program 
support system. 

The ideological foundation for DREAM is the belief 
that architectural design requires a language which expresses 
specifications in requirements-oriented rather than implemen- 
tation-oriented terms. Abstraction is therefore supported 
since specifications possess a behavior or effect orientation 
instead of an operation or cause orientation. This feature 
also facilitates definition of module boundaries and inter- 
actions. Riddle outlines the following attributes required 
of a design description language: 

1. analysis oriented 

2 . unambiguous 

3. modular 

4. hierarchical 
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5. 



incremental 



6. outward directed 

7 . redundant 

8. modification oriented 

9. guidance oriented 

10. non-prescriptive [Ref. 31]. 

4 . Jackson Design Method 

Developed by M. Jackson, this method is a three step 
technique which involves both graphical and non-graphical 
notations. First, the structure of the data is graphically 
represented as trees; these data structures are then composed 
into a hierarchy of the program structure. Finally, the 
executable operations required are listed, and each is allo- 
cated to its proper place in the program structure. This 
list forms the basis for a program implementation since these 
operations are elementary executable statements of a program 
language. Every operation must have operands which are data 
objects [Ref. 32]. This methodology appears to emphasize the 
description of the problem and its solution, particularly as 
a step by step sequence of processes. This is in consonance 
with its classification as a detailed design technique; 
nevertheless, it hinders its ability to abstract and modularize 
functions . 

5 . Structured Flowcharts 

Structured Flowcharting (also called Nassi-Shneiderman 
Charting) is a graphical technique developed as an alternative 
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to traditional flowcharting in order to represent, visually, 
structured programming techniques. Its primary benefit is 
to document a design which has already been developed, and 
it is therefore useful during later stages of the design process. 
Claimed advantages include: 

1. well defined and visible scope of iteration 

2. well defined and visible scope of IF-THEN-ELSE 

3. scope of local and global variables is obvious 

4. arbitrary transfers of control are impossible 

5. complete thought structures on one page [Ref. 33]. 

Nassi-Shneiderman diagrams represent standard programming 
constructs which might occur in any structured programming 
language. It should be noted that Structured Flowcharting 
is a low level technique, and as such, its ability to abstract 
is limited. 

6. PPL 

PDL (Program Design Language) is an algorithmic language 
which uses a semi-formal syntax and structured format to 
describe processes. Syntax and format can vary greatly from 
designer to designer. Like structured flowcharts, it is more 
appropriate during later stages of the design process, although 
its abstraction abilities do permit top-down, stepwise refine- 
ment from general concepts to specific implementations. Its 
primary purpose is to communicate ideas to people, not com- 
puters; however, there have been automated PDL's [Ref. 34]. 
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IV. REUSABLE SOFTWARE DESIGN LITERATURE 



In this chapter, the current literature on reusable soft- 
ware is reviewed to ascertain the current status of design 
vis-a-vis reusability. The literature on this subject is 
rather sparse, although the recent conference on reusable 
software sponsored by International Telephone and Telegraph 
in September 1983 indicates that this is changing. This re- 
view adopts a somewhat chronological approach, beginning with 
the oldest references first. Only points pertinent to the 
design phase are presented. 

A. RATHEON EXPERIENCE 

Although he was not the first to develop the idea of 
reusable software, Robert Lanergan can be credited as the 
first to popularize the concept in a series of articles 
beginning in 1978 on actual implementation of a reusable 
methodology at Raytheon, Inc. The importance of this work 
stems from his prolific writing on and personal advocacy of 
reusable software as a possible means of improving software 
development productivity. His work includes several design 
related issues which are outlined: 

1. The methodology emphasizes functional modularity to 
develop reusable modules. 

2. A top-down approach is used in which high-level logic 
is designed and coded first. 
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3. Programs are composed of two types of reusable 
modules (functional modules and logic structures) plus 
some unique factors. 

4. Functional modules are designed and developed for a 
specific purpose. These are categorized and cataloged 
for reuse. 

5. Logic structure is a cluster of small redundant func- 
tional modules designed hierarchically with a prewritten 
Identification Environment, Data and Procedure Divisions. 
There are three basic types of logic structures: 

(a) select and/or edit, (b) update and (c) report. 

Each of these may or may not have a sort. Crucial to 
the construction of a logic structure is a central 
supporting paragraph. 

The Raytheon methodology is a COBOL-based methodology oriented 
toward business applications; indeed, the categorization of 
logic structures into the three basic types listed above is 
based on Lanergan ' s view that these are the "only ... things 
you can do with a business computer program" [Ref. 35] . 

This methodology is interesting in that it advocates modulari- 
zation of functions, top-down design, and a two level archi- 
tecture composed of a framework logic structure to which 
interchangeable functional modules may be attached. 

For all the credit which must be given him for populariz- 
ing the concept, there are, however, several criticisms of 
his work. First, his methodology does not seem to be 
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generalizable to the field at large, although there is no 
indication that he intends it to be. As he says, the tech- 
nique is ADP oriented. Nevertheless, a great service could 
have been performed if he had attempted to communicate his 
methodology better and to derive some general principles of 
reusable design. This points out a second criticism; his 
articles do not sufficiently explain his methodology. The 
reader is left with only a superficial grasp of his technique. 

A third criticism derives from the fact that his methodology 
is not an instance of "pure reusability" — components are 

3 

reusable only within the same program systems . A minor 
criticism concerns lack of substantiation of his reported 
productivity increases. Finally, Lanergan ' s articles and 
methodology emphasize reuse of code; as this thesis proposes, 
this is not where emphasis on reuse should be. For all these 
criticisms, his is still the most noted contribution to 
reusability to date. 

B. ASSORTED REFERENCES 

Between Robert Lanergan ' s initial paper in 1978 and the 
ITT Workshop on Reusability in 1983, there was only one paper 
devoted solely to the topic of reusability and software design, 
and that was Bertrand Meyer's paper. There are, however, a 
few brief discussions of the subject in various articles. 
Rauch-Hindin quotes a TRW employee's explanation for the 
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Personal telephone conversation with Robert Lanergan. 
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non-acceptance of modules of reusable code as being in the 
assumptions made when these modules were originally designed. 
Reuse requires that the implementor change either his design 
or the module's code if these assumptions are not consistent 
with the assumptions of the current design. An implementor 
with many modules, each developed separately, faces complex 
interfacing problems and may be forced to alter his design 
to assure that everything fits [Ref. 36]. Rauch-Hindin quotes 
others as advocating that reusable modules must be specifically 
designed for reuse, must have simple interfaces, and must have 
well defined functionality or high cohesion (a single, well- 
defined purpose) . The design must also incorporate the need 
for clean interfaces [Ref. 37] . 

In another article on reusable software, Rauch-Hindin 
again included some comments that are pertinent to reuse of 
design. First, she pointed out that a major obstacle to 
reuse of modules is lack of standardization of "meaning and 
representation of data and parameters." One of the reasons 
for the success of reusable mathematical subroutines has 
been their well-defined algorithmic specifications and param- 
eteric information. She also discusses Ada "packages" which 
possess enhanced interface capabilities in their specification 
sections, as well as criticality of communicating information 
about reusable modules to potential users [Ref. 38] . Through- 
out her series of articles, Rauch-Hindin stressed several 
things regarding software reuse and design: 
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1. The importance of initially designing modules with 
reuse in mind; modules not designed in this way will 
be difficult to reuse. 

2. The importance of the module user being able to acquire 
more information about reusable modules in addition to 
just the code itself, particularly assumptions made 

at design time. 

3. The criticality of interface issues in linking modules. 

4. The importance of decomposition into highly cohesive 
modules . 

5. Standardization of "meaning and representation of 

data and parameters" as a means of enhancing reusability. 

Bertrand Meyer addresses design of reusable software and 
proposes abstract data types as a possible solution to reuse 
in a 1982 paper. He sees the subprogram package — a group 
of routines called by any program — as being the key to 
implementation. These packages will be used by others if 
they are designed for simplicity, self-restraint, ease of 
use, homogeneity, and safety. By simplicity, he means that 
all information needed to use a package should be available 
in the package "without further reference to any written 
document." Self-restraint deals with the idea that subpro- 
gram packages perform general utility tasks and not esoteric 
or interesting problems. Ease of use includes good documen- 
tation and consistency of design (for example, standardized 
parameter order) . By homogeneity, Meyer again is referring 
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to subprogram parameters and need to limit their number, as 
well as naming conventions for subprogram names. Safety 
refers to error handling capabilities of the subprogram 
package. A subprogram package itself is "the conscious 
implementation of one or more abstract data types." In 
addition, this is supported by the concept of information 
hiding, which separates public and private information con- 
tained in these packages [Ref. 39] . 

C. JLC PANEL ON SOFTWARE REUSABILITY 

As was mentioned in Chapter I , the Proceedings of the 
Joint Logistics Commanders Software Workshop held in 1981 
contained a panel on software reusability; the panel 
specifically advocated reuse of intangible design as well as 
other products of the software life cycle. In a section on 
functional design reuse, the panel stated that reusable 
design must be "clearly identified, locatable, and under- 
standable." It perceived modular partitioning as a particu- 
larly crucial step which requires unique and, as yet, undeveloped 
techniques. To be identifiable, a design must be described 
by the requirements it fulfills and functions it implements. 

The panel stated that a "top-down hierarchical exposition of 
the design is mandatory." A design should consist of several 
levels, each level showing successively more detail. This 
facilitates comprehensibility by limiting number of internal 
subprocesses necessary to be understood. The panel also 
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advocated a standardized means of design exposition, includ- 
ing textual or graphical notation [Ref. 40]. 

D. ITT WORKSHOP ON REUSABILITY 

The literature on software reusability has improved 
considerably with publication of the Workshop on Reusability 
in Programming in September 1983. This is not the case with 
respect to the topic of reusable design. However, there are 
several articles in which this issue is addressed, and each 
of these is analyzed separately. 

1 . Doberkat, Dubinsky and Schwartz 

In their paper outlining their work with a very high 
level language, SETL, the above authors attempt a definition 
of reusability of design: 

...the ability to convey the overall procedural struc- 
ture and principal data designs of large complex 
programs to implementation groups wishing to develop 
the same or similar functions in new environments... 

According to the authors, such an endeavor requires a 

specification language which allows the complete description 

of significant abstract features, while suppressing design- 

irrelevant details. Such a language does not now exist 

[Ref. 41]. 

2 . Horowitz and Munson 

Horowitz and Munson, in a general review of the 
current state of research on reusable software, devote a 
section to reusable design. They summarize the essential 
idea of reusable design as being a formal study of a particular 
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application domain (domain analysis) and using "artifacts" 
of this study to develop an automated system. These "arti- 
facts" include data types in the domain, and various con- 
straints on these processes. Reuse occurs "when subsequent 
efforts to automate specific instances of the domain make 
use of the previous artifacts that were developed." A 
central problem lies in the medium by which these artifacts 
are recorded for reuse; specifically, in what language are 
they to be recorded, are they to be immediately translated 
into modules, or is there some other approach? The authors 
then describe two example approaches taken by Neighbors 
(DRACO) and Rice (Automatic Software Generation System) 

[Ref. 42]. 

3 . Deutsch 

Smalltalk-80, according to an article by Peter Deutsch, 
facilitates reuse of design through its data abstraction 
capabilities. Reuse of algorithms is hampered by their 
dependence on detailed implementation of the data they 
manipulate. Data abstraction circumvents this by packaging 
a data type with its parameters; when a procedure is invoked 
using objects of that data type, the correct parameters for 
that type are automatically substituted into the procedure. 

In Smalltalk-80 abstract data types are hierarchically 
arranged. Smalltalk-80 also employs the concept of a class, 
which consists of a description of a data object and a set 
of named procedures having access to this description. 
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Abstract classes can include reusable algorithms. Smalltalk- 
80 extends this idea through its concept of a framework, 
which is a collection of abstract classes and their algorithms. 
As Deutsch described it, "particular applications can insert 
their own specialized code (into the framework) by constructing 
concrete subclasses," thereby enabling reuse [Ref. 43]. 

E. SUMMARY AND ANALYSIS OF SOFTWARE DESIGN LITERATURE 

Our primary impression of the current state of reusable 
software design as gained from a review' of the literature to 
date on the subject is that it is very primitive. Obviously, 
the subject has not received a lot of attention. Most of 
the discussion is presented from a very narrow focus, usually 
based on observations derived from specific research conducted 
by the author. What is needed is a comprehensive analysis 
of the topic with a coherent, organized and comprehensive 
theoretical foundation for the subject. The synopsis pre- 
sented below is the first step in doing this. 

First and foremost, no single design approach emerges in 
the literature as preeminent; there are as many methodologies 
as there are authors. None of the traditional techniques, 
such as PDL, are advocated or even studied in the reusa- 
bility literature. There does seem to be a consensus that 
any design methodology tased on reusability must be a top- 
down approach. Most authors emphasize a software design 
technique which allows a high degree of functional modulari- 
zation, abstraction of multiple levels in the design, structured 
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design and programming concepts, and information hiding. 
More recently, the literature has begun to investigate do- 
main analysis as a possible design methodology pertinent to 
the reusability problem. Aside from these areas of general 
consensus, there are other, less-agreed to ideas on the 
characteristics of a reusable design methodology: 

1. In business ADP, reuable modules are of two types — 
functional modules and logic structures. 

2. Reuse of design requires knowledge of assumptions 

4 

under which the design was developed . 

3. Interface issues are important at design time. 

4. Software must be specifically designed for reuse in 
order to be reused. 

5. Designs should strive for simple, clean interfaces. 

6. Designs of modules should exhibit high cohesion. 

7. Communication of the design to the user who will 
reuse it is important and is facilitated by certain 
characteristics of the design itself, such as 
simplicity, self-restraint, homogeneity, ease of 
use, and safety, as well as means of access to the 
design . 

8. Standardized design notation/exposition is advocated. 



4 

Professor Normal Lyons of the Naval Postgraduate 
School, Monterey, Ca., states that this is essentially 
what minicomputer original equipment manufacturers do when 
they specialize in a given industry. Much of the systems 
analysis work they do is reusable because they seldom 
venture outside that industry. 
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The above reinforces our initial comments on the hap- 
hazard state of current thinking; current literature is 
sparse, fragmented, and no overall authoritative work 
exists. Part of the problem lies in the way the reusability 
literature refers to design. There are actually two aspects 
to design; the first is design of the reusable components 
themselves; that is, what should they look like, while the 
second is design using reusable components; that is, what 
methodology should be used. The first aspect influences the 
second. This distinction should be kept in mind during the 
next chapter since it is the latter which is emphasized. 
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V. GUIDELINES FOR A REUSABLE DESIGN METHODOLOGY 



This chapter seeks to develop guidelines for choosing 
or developing an appropriate design methodology which 
incorporates reusability. The approach is three-fold. 

First, a design scenario incorporating reuse of existing 
components is proposed; from this, those characteristics 
which a design methodology must possess are derived. Next, 
design methodologies reviewed in Chapter III are compared 
to see which possesses most of these characteristics. 

Finally, an idealized reusable design methodology is 
discussed. 

A. A PROPOSED REUSABLE DESIGN SCENARIO 

To date, no one has proposed a concrete methodology of 
software design which incorporates reuse of components. 
Lanergan describes his overall approach in general terms 
without really honing in on design specifics, while Rice 
and Schwetman compare reusable software development to an 
eight step electronic component fabrication process [Ref. 

44] . Chandersekaran and Perriens briefly mention a three 
stage approach to building new software systems from existing 
parts [Ref. 45] . This situation is remiss; before an 
appropriate technique can be chosen or developed, one must 
know what the reusable design process will look like. For 
this reason, the following scenario is proposed. 
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A designer starts from a set of requirements, either 
formal or informal. From this, he develops an appropriate 
structure for the overall design. He then begins a process 
of design decomposition into smaller design modules, and 
for each module, he checks to see if an existing design com- 
ponent exists which can be plugged into the overall design 
at this point. If it does, then that portion in the design 
is complete, and he proceeds to other modules. If not, 
decomposition of that module continues. When decomposition 
is no longer possible and a reusable module for a particular 
function does not exist, only then is a new module designed, 
using a standardized methodology which emphasizes designing 
modules for reuse. Also, if it is possible to reuse an 
existing component by modifying it, this is permissible, but 
a completely different component is thus created. 

When flaws in the design are discovered, correction 
involves isolating the appropriate module or modules' 
location (s) and redesigning via the above process. Isolation 
of location means determining which levels in the decomposi- 
tion are affected. 

Code for modules designed in this manner are produced 
in one of two ways; first, each module is coded at completion 
of detailed design and the code archived along with design 
notation, design assumptions and documentation. Alternatively, 
only these latter three are archived, and coding waits until 
an actual implementation is required. This latter method 
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seems preferable in terms of storage cost and implementation 
language flexibility. Thus, the designer's job is finished 
when he has assembled a complete, detailed design composed 
of both previously developed and new modules in the design 
notation. At this point implementation into code is an 
automatic process. Reusable code, as currently envisioned, 
would not exist under this option. For each particular 
existing component, there could be standard sets of source 
code statements in several possible program languages. 

From the above, it is evident that concern should not 
be with structure or appearance of coded modules; instead, 
it is with appearance of design level modules, both architec- 
tural and detailed design levels. It is envisioned that a 
designer at any stage in the architectural or detailed de- 
sign process may find a previously built module which appro- 
priately fulfills a function within the overall design. 

This module may itself be composed of many previously built 
modules. At the lowest level of detail design, each module 
is a small, highly cohesive module; this smallness implies 
a large number of modules, emphasizing what has consistently 
been pointed out in the literature; i.e., interfaces are 
extremely crucial. 

No one at this point in time can say what reusable soft- 
ware will ultimately look like; for now, the best estimate 
is that reusable software will be small packages. These 
packages will be highly modular, performing a single, well- 
defined function. The packages will consist of the 
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architectural design notation, design assumptions, detailed 
design notation, and documentation. Ideally, the detailed 
design notation will be standardized and of a generic 
nature, in order to permit implementation in any programming 
language. It should be of a form so that source code can be 
easily produced, directly from the detailed design notation, 
once appropriate program language is selected. 

B. REUSABLE DESIGN METHODOLOGY CHARACTERISTICS 

From the scenario proposed in the last section, the 
characteristics of a design methodology which would facili- 
tate reuse of components can be inferred. Such a methodology 
should: 

1. facilitate modular decomposition 

2. possess a top-down approach 

3. permit abstraction of lower levels during decomposition 
(although these first three are closely related, 

there is not necessarily a one for one correspondence; 
i.e., a methodology may greatly facilitate a top-down 
approach to design but be less effective in enhancing 
abstraction) . 

4 . be composed of one methodology which incorporates 
facilities for both architectural and detailed design 

5. possess a textual design notation at the architectural 
level, possibly supplemented by a graphical notation 

6. possess a textual notation at the detail design 
level 
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7 . 



provide for a correspondence between modules at the 
architectural level and modules at the detail level 



(i.e., if a particular architectural module is selected, 
a certain corresponding detail design module or modules 
would follow) 

8. permit textual commenting, separate from architectural 
and detailed design notations, to accommodate the 
need for assumptions and documentation. 

From the previous chapter, the literature indicates that 
this methodology should also: 

9. support information hiding (specifically, it should not 
be necessary to know the implementation of one module 
in order to implement another module) 

10. support simple, clean module interfaces and explicit 
parameterization (the ability to define number, form 
and type of parameters and to do so in a manner which 
is not cumbersome to the prospective user is a very 
important element of any reusable methodology) 

11. be simple and easy to use 

12. possess a standardized format known to all users. 

C. CURRENT DESIGN METHODOLOGIES COMPARISON 

The task of comparing existing design methodologies to 
see which best facilitates a reusable approach can most 
easily be accomplished via Table 1. Along the vertical axis, 
each of the twelve factors cited in the previous section is 
listed; horizontally, each of the six existing design 
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TABLE 1 



CURRENT DESIGN METHODOLOGIES COMPARISON 



Modular 

Decomposition 

Top 

Down 



Structured Jackson Structured 

Design HIPO DREAM Design Flowchart PPL Max = 18 



0 



13 



14 



Abstraction 



15 



One 

Methodology 

Textual 

Architectural 

Notation 



0 0 



Textual 

Detailed 

Notation 



0 0 



Architectural- 

Detailed 

Correspondence 

Textual 

Comnenting 

Information 

Hiding 

Clean Inter- 

Faces/Explicit 

Parameters 



0 0 



0 0 



3 3 



1 3 



0 

0 



1 

1 



11 



Simple, Easy 
to Use 



3 1 



13 



Standard 

Format/ 

Language 



3 3 



14 



Max = 36 



21 



20 22 



20 



0 = None 1 = Lew 2 = Medium 3 = High 
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techniques mentioned in the previous chapter is listed. For 
each design technique, a number is placed in the appropriate 
row indicating extent to which that technique facilitates 
that particular factor listed on the vertical axis. The 
numbers range from zero (does not facilitate) to three 
(strongly facilitates); thus for example, HIPO is rated high 
in abstraction capabilities (3) , while it is rated as having 
no textual commenting capabilities (0) . In addition, each 
column is summed to give a relative ranking of each particu- 
lar design technique in relation to the others and in relation 
to an ideal maximum score of 36, this being the best score 
attainable if a methodology possessed all characteristics to 
the maximum extent required for implementing reusable design. 
Finally, each row is summed to give an indication of the 
current status of existing design methodologies as regards 
their ability to support each of the twelve requirements of 
a reusable design methodology. Maximum score possible in 
this case is 18. 

As Table 1 shows, no existing design methodology com- 
pletely meets all the criteria required to support reusable 
design. Of 36 possible points, DREAM scores highest of any 
methodology with 22; Jackson Design Methodology and Struc- 
tured Flowcharting score least with eight each. A significant 
but expected pattern also occurs in that, in general, archi- 
tectural design methodologies' scores seem to be decidedly 
higher than those for detailed design techniques, PDL being 
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the exception. When the row scores for each of the twelve 
categories are compared to the maximum of 18, wide variation 
is encountered. Current methodologies are most inadequate in 
the category "Architectural-Detailed Correspondence" (score = 0) , 
while highest in the "Abstraction" category (score = 15). 

The following categories are considered very deficient (scores 
less than 50% of maximum possible) : 

1. One Methodology 

2. Textual Architectural Notation 

3. Textual Detailed Notation 

4. Architectural-Detailed Notation Correspondence 

5 . Textual Commenting 

6. Clean Interfaces/Explicit Parameters. 

It is concluded from this that no existing design methodology 
is adequate for reusable design and that this is probably 
one of the main reasons why reusable software has not been 
more widely implemented. 

D. AN IDEALIZED REUSABLE DESIGN METHODOLOGY 

Ideally, a reusable design methodology supports all 
twelve characteristics mentioned in the previous section. 

Such a methodology allows the designer more freedom at higher 
levels in the design to decompose as he sees fit, while pro- 
viding opportunities at lower levels to incorporate previously 
designed modules. At the lowest level of detail, there is a 
direct correspondence between textual design statements and 
source code implementation. Linkage between architectural 
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textual statements (and graphical notation) and detailed 
text is also direct. The methodology possesses a standardized, 
formal syntax and grammar. 

The design notation must possess capabilities to communi- 
cate module interfaces effectively; this is probably the 
most important feature of the design language. The language 
must allow accurate representation of required module inputs 
and generated outputs, including their number, types, and 
order [Ref. 46]. We suspect that the more "generic" a module 
is, the larger and more complex it will be; this results in 
more complicated interfaces. This is at odds with Meyer's 
advocacy of short parameter lists, and it argues for larger 
numbers of "non-generic" modules. 
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VI. OTHER ISSUES 



There are a number of issues important to the topic of 
reusable software, and, as such, they relate to the main 
topic of this thesis, reusable software design. These issues 
are primarily of an administrative nature, such as that of 
project organization. In discussing these issues, the format 
used by the panel on reusability of the Joint Logistics 
Commanders Software Workshop is adopted [Ref. 47]; this format 
addresses all major administrative issues in reusability. 
During this discussion, an attempt is made to emphasize 
those aspects which are of importance to the central theme 
of design. As comments about reusable software are made, 
the reader should bear in mind that they apply directly to 
reusable design. 

A. PROJECT ORGANIZATION AND CONTROL 

It is likely that the actual adoption of reusable 
methodologies will be done by individuals and organizations 
who perceive them as being more cost effective, easier to 
use, and/or more time-saving than traditional software 
development methodologies. This thesis agrees with the JLC 
panel's position that adoption of reusable development 
methodologies will require differences in or special emphasis 
in certain areas of project management. JLC feels that these 
differences justify creation, within each organization 
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developing software, of an activity devoted to overseeing 
reusable software, the Reusable Software Organization (RUSO) . 
This author does not feel at this time that establishment 
of such a specific organizational entity to oversee reusa- 
bility is required. Actual implementations of reusable 
software at Raytheon [Ref. 48] and Hartford Insurance [Ref. 
49] have not been accompanied by establishment of RUSO-like 
activities . 

There is need, however, for assurance that functions 
which a RUSO might be responsible for are carried out. 

These would include: 

1. establishment and monitoring of organizational reuse 
goals 

2. development of strategic and tactical reuse plans 

3. establishment of reuse standards and guidelines 

4. evaluation of reuse methodologies and tools 

5. responsibility for reuse quality assurance 

6. establishment and maintenance of reuse archival 
facilities and activities. 

Actual establishment of a RUSO is best dictated by size of 
the organization and software development effort. 

B. QUALITY ASSURANCE/TESTING 

In the areas of quality assurance and software testing, 
there exist two distinct views regarding reusable software. 
The first says that because this software is reused among 
many different programs in a variety of environments, it 
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must be subjected to a rigorous testing and certification 
procedure. In essence, a higher level of testing than on 
non-reusable software is imposed initially. However, once a 
piece of reusable software is thus certified, it may be used 
by a wide range of users with confidence and with reduced 
need for repeated testing in every new application into which 
the reusable component is inserted. The second view derives 
from the philosophy that since testing only reveals presence 
of errors and never proves their total absence, development 
of perfect software through testing is impractical. This 
view says that a more practical approach to reusable software 
certification, and one which will encourage production of re- 
usable components, is merely to require the component's 
developer to document adequately the level of testing to 
which a component has been subjected. It is then the 
responsibility of the user of that component to test beyond 
this level if necessary. This last point highlights a prob- 
lem with the first view, in that not all applications require 
the same standards of testing — some applications are less 
critical. Why require such strict certification standards 
when they are not necessary in all cases? Finally, reduced 
testing standards may encourage component development. 

At the intra-organizational level, there probably is 
need for some entity to establish minimal quality assurance/ 
testing/certification standards. As the JLC report recom- 
mends, this appropriately belongs to a RUSO-like activity. 
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Also the JLC report stated that one important result of 
utilizing previously tested components is an overall reduced 
level of testing at the component level, although this state- 
ment should be tempered by the analysis in the previous 
paragraph. System integration testing would not be affected. 
In addition, the JLC report recommends a top-down approach 
to testing, although no rationale for its preference over 
other testing methods is given. For this and other reasons, 
appropriate testing methodologies for reusable software is 
an excellent subject for further research. 

C. REUSE ARCHIVAL ISSUES 

Aside from development of an actual reusable software 
methodology, development of systems and techniques for 
archiving reusable software is the most important task to 
be accomplished. Importance of this area to an effective 
reusable methodology cannot be overemphasized, for it is 
ease of locating required components which will make or 
break the methodology. Additionally, this thesis feels that 
to the greatest extent possible, design of the archival 
system should depend upon design of the reusable methodology; 
that is, we think that designing archival systems before 
concrete details of the methodology are developed is like 
"putting the cart before the horse." 

It is possible, based on analysis in this thesis, to make 
some predictions regarding reusable archival systems. First, 
if the organization establishes a RUSO, then that body should 
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establish a "library" to perform this archival function whose 
primary task is to address recapture of software components. 

It is uncertain at this time what form the archival entity 
will take, whether or not a "library-like" form is best re- 
mains to be seen. JLC also made an excellent recommendation 
on establishment of a Reusable Software Change Control Board 
(RCCB) whose purpose is "to maintain the integrity of the 
(reusable software) and its library." It is "sole authority 
for the approval, disapproval, or deferral of proposed 
changes." Someone within the RUSO should approve all com- 
ponents entering the library. Primary activities of the 
library would involve distribution and dissemination of 
reusable software. 

The library itself would probably consist of a combina- 
tion of manual and automated archival facilities. Foremost 
of these are indexing and cataloging facilities for storage 
and retrieval of reusable software developed in house, as 
well as facilities for indexing externally developed reusable 
software. These latter might be similar to components 
catalogs . 

From the analysis in previous chapters, it is felt that, 
from a design standpoint, library facilities should be oriented 
toward archival of textual material, although capabilities 
should be present to handle graphical notation as well. How- 
ever, when the entire range of material developed during 
the entire reusable software life cycle is considered, the 
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orientation might be different. As to what sorts of things 
will be archived, the following are postulated: 

1. Architectural Design Notation 

2. Detailed Design Notation 

3. Design Assumptions 

4. Documentation 

5. Test Plans and Results 

6 . Code . 

As was discussed in an earlier chapter, the first four items 
above exist as modules designed in a standardized reusable 
design language; archival considerations should take this 
into account. Test plans would not be in this same language, 
but facilities for linking a module's design language, test 
plans and code should exist. Presence of code in the library 
depends on the overall reusable methodology itself. 

There are numerous other issues involved in reusable 
software — reimbursement, program language selection, 
reusable software maintenance, and so on. This chapter 
attempts to address only the most important. Certainly, 
further research on those discussed, and those not discussed, 
is warranted. 
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VII. CONCLUSIONS AND RECOMMENDATIONS 



In studying reusable software, its most outstanding 
characteristic is its newness as a topic of research and 
analysis. Although reuse of software has existed for some 
time, consideration of the idea does not appear in the 
literature until the late 1970' s. It is only within the 
last two years that reusable software has received serious 
analysis. There are two basic reasons why this topic is 
generating such increased enthusiasm; first is that it is 
seen as a possible solution to the software crisis. All 
trends show an explosive growth in demand for software products, 
and reuse of these products after development represents a 
common-sense solution. Second, the idea that software is a 
capital asset is a novel way of looking at something that 
should have been apparent from the start. In the purest 
definition of the term, a capital asset is something which 
is not "used up" during its operation; this is a primary 
characteristic of s.oftware. Interest in reuse of software 
stems from an unconscious realization that it possesses this 
characteristic of all capital assets. 

As with all new endeavors of study, reusable software 
is undergoing a definitional phase. There are several 
aspects to this statement. First, there is no commonly 
accepted, authoritative definition of the term; it is strictly 
a "buzzword." Hopefully, the attempt in Chapter II can serve 
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as a beginning for dialog in this area. Second, there is 
no generally accepted organization to or boundaries for 
research — there is no "taxonomy" of the subject. Therefore, 
the literature contains almost as many directions of research 
on reusable software as it does authors. This thesis pro- 
poses the software life cycle as the most appropriate struc- 
ture for organizing thought and research on this topic. 

Finally, lack of an accepted definition results in a situation 
where everyone has his own idea as to what is reusable. This 
thesis advocates reuse of architectural design, detailed 
design, design assumptions, code, documentation and test 
plans--essentially , all the products of the life cycle. 

The particular emphasis of this thesis, software design, 
is chosen because it is felt to be the most crucial product 
of the life cycle from a reuse standpoint. The reviews of 
existing software design methodologies included in Chapter 

III and of literature on reusable software design in Chapter 

IV show how no current design methodology is suitable from a 
reuse standpoint and how woefully inadequate is research into 
this area. Accordingly, a reusable design scenario is 
developed in Chapter V as a basis for developing guidelines 
for a design methodology which incorporates reuse of existing 
components. Development of this methodology is seen as the 
most important step to be taken in realizing reusable software. 

Chapter VI is an attempt to overview briefly several 
other topics of importance to reusable software in general, 
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and reusable design in particular. However, decisions on 
these areas are deemed appropriate only after decisions 
regarding design methodology have been made. This does not 
minimize their importance to the effort. 

Recommendations of this thesis are centered on the strong 
need for further research into topics which we have only 
been able to explore briefly. First and foremost, a compre- 
hensive, authoritative review of the entire subject of 
reusable software is needed; this task is much too large for 
a thesis-length endeavor. Second, further research into the 
specific area of reusable design methodologies is needed. 

Two questions which might be pursued are: (1) Can present 

methodologies be adapted to accommodate reuse, and (2) What 
characteristics should such a methodology possess? Research 
into the other issues mentioned in Chapter VI is also required; 
the areas of archival requirements and quality assurance 
requirements present excellent future thesis topics. 
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